home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf43_docs / administrators / overview < prev    next >
Encoding:
Text File  |  1986-02-27  |  5.4 KB  |  146 lines

  1. .\".AU
  2. .\"Douglas P. Kingston III
  3. .\".AI
  4. .\"Ballistic Research Laboratory
  5. .\"USA AMCCOM
  6. .\"Aberdeen Proving Ground, Maryland.  21005
  7. .\"(301) 278-6651
  8. .NH 1
  9. Overview
  10. .NH 2
  11. Introduction
  12. .PP
  13. The \*M mail system has seen a great deal of development over the
  14. past several years and has involved a large number of people.
  15. This guide is an attempt to gather together the information
  16. which until now was only passed along as folklore or learned by reading
  17. the code.  The guide is divided into five parts.  The Overview will attempt
  18. to give a summary of the contents of the \*M distribution and where
  19. to look for more information.
  20. The next section explains, step by step, how to compile your own
  21. tailored \*M.
  22. The following sections cover runtime tailoring from the configuration
  23. file, building host, domain, and alias tables, and finally tuning
  24. \*M for best performance on your system.
  25. The \*M programs are all linked with a library that contains a default
  26. compiled-in configuration (which may be very scant).
  27. The compiled-in values can be overridden or augmented by the
  28. runtime tailoring file and tables.
  29. .NH 2
  30. Available Channels
  31. .NH 3
  32. The Local Channel
  33. .PP
  34. The local channel is responsible for delivering mail to mailboxes and
  35. processes on the local machine.  It normally delivers directly to
  36. a mailbox file in the user's home directory or /usr/spool/mail.
  37. It is also capable of delivering to processes or alternate files under
  38. the control of the alias file and/or the user's own "maildelivery"
  39. file, as described in manual section \fImaildelivery(5)\fR.  There
  40. is also provision for a system default maildelivery file if the user
  41. does not supply one.
  42. .NH 3
  43. The List Channel
  44. .PP
  45. The list channel is a special channel that remails messages.
  46. The channel simply invokes \fBsubmit\fR and feeds the addresses
  47. and text back into the \*M mail system.
  48. This is often useful to avoid long address verification
  49. procedures at posting time or to force the verification
  50. take place in the background.  The list channel also knows how
  51. to replace the return address of a message with the list-request
  52. address when appropriate.
  53. .NH 3
  54. The SMTP Channel
  55. .PP
  56. This channel implements the Simple Mail Transfer Protocol as described
  57. in RFC-821.  There is currently code to support the 4.1aBSD, 4.2BSD,
  58. and 4.3BSD network semantics,
  59. BBN TCP network semantics, and 2.9BSD semantics.
  60. .NH 3
  61. The Delay Channel
  62. .PP
  63. Generally used in conjunction with nameserver support.
  64. If there is a nameserver failure for whatever reason, and this channel
  65. is configured, the mail will be conditionally accepted and queued
  66. to the delay channel.
  67. The delay channel will re-submit the mail at a later date until a
  68. definitive reply is received from the nameserver.
  69. .NH 3
  70. The BadUsers Channel
  71. .PP
  72. There is no specific code associated with this channel.
  73. Submit knows if it finds a username it does not know, it can
  74. queue it on this channel for forwarding to another host that
  75. has a better user database.
  76. The channel name is hardcoded as ``badusers''.
  77. .NH 3
  78. The BadHosts Channel
  79. .PP
  80. Like the BadUsers channel, except this is for mail to hosts
  81. that submit does not know.
  82. The channel name is hardcoded as ``badhosts''.
  83. .NH 3
  84. The Phone Channel
  85. .PP
  86. The PhoneNet dialup network protocol is supported by this channel.
  87. PhoneNet is a dialup package developed at UDEL
  88. and used extensively by the CSNET and the Army
  89. as a link layer for \*M for its hosts not directly connected
  90. to a Local or Wide-Area network.
  91. .NH 3
  92. The Pobox Channel
  93. .PP
  94. This is a do-nothing channel that allows queued mail to be picked
  95. up by another process.  The Pobox channel is typically used in a PhoneNet
  96. slave site, but is by no means limited to this.  In the PhoneNet application,
  97. the Pobox channel passes mail from the queue (via deliver) to the phone (via
  98. the PhoneNet Slave program).
  99. .NH 3
  100. The UUCP Channel
  101. .PP
  102. UUCP mailing is supported by this channel.
  103. Addresses are converted as necessary.
  104. Inbound mail is converted into RFC822 format, preserving
  105. existing 822 format header lines.
  106. Outbound, ``From<space>'' lines are added
  107. and rmail arguments
  108. are generated in UUCP bang route format.
  109. The channel will make use of pathalias output paths to simplify
  110. incoming addresses and to route outgoing addresses.
  111. .NH 3
  112. The NIFTP Channel
  113. .PP
  114. NIFTP is a batched file transfer facility used in the UK.  This channel
  115. uses NIFTP to send and receive mail by creating batched requests that send
  116. mail as files.
  117. .PP
  118. The NIFTP channel produces message files formatted according to the
  119. JNT Mail Protocol.  These are transferred by a file transfer protocol,
  120. typically the UK NIFTP (Network Independent FTP), to the remote site.
  121. .NH 3
  122. The BBoards+POP Channel
  123. .PP
  124. This channel is used to interface into the BBoards system that is part
  125. of MH.{4,5,&6} as developed at UCI.
  126. The channel is also compiled to a slightly different version for
  127. supporting Post Office box Protocol (POP).  (Provided by Marshall Rose)
  128. .NH 3
  129. The EAN Channel
  130. .PP
  131. This channel is used to access the EAN X.400 system produced by the 
  132. University of British Columbia.
  133. .NH 3
  134. The Program Channel
  135. .PP
  136. This channel is used to interface well behaved programs to the \*M mail
  137. system.
  138. It does no more than try to reliably pass mail in or out of \*M.
  139. Systems that require special reformatting of the message (such
  140. as UUCP) cannot use this channel.
  141. For example this channel could be used to interface the ACSNET
  142. network or a Batch SMTP implementation both of which prefer
  143. to deal with RFC822 format mail.
  144. This is a new channel and may change somewhat in the future to make it
  145. more powerful.
  146.